[sw,dv] Add SW-DV logging by martin-velay · Pull Request #600 · lowRISC/mocha

martin-velay · 2026-06-04T15:56:10Z

Related to this issue: #261

rswarbrick

A couple of nitty comments but this looks nice.

(And the review took me a while: I hadn't seen the clever variadic macro trick before!)

martin-velay · 2026-07-15T09:42:20Z

I've just rebased and fix the merge conflicts. There was also an issue for CHERI tests. Now Verilator tests pass and the UVM tests too (new tests dv_log_smoketest and dv_log_smoketest_cheri in test_framework regression):

dvsim hw/top_chip/dv/top_chip_sim_cfg.hjson -i test_framework
...
          [   legend    ]: [S: scheduled, Q: queued, R: running, P: passed, F: failed, K: killed, T: total]                                                                                               
00:01:07  [    build    ]: [S:         0, Q:      0, R:       0, P:      1, F:      0, K:      0, T:     1] 100%                                                                                          
00:01:43  [     run     ]: [S:         0, Q:      0, R:       0, P:      6, F:      0, K:      0, T:     6] 100%  
...

And the log gives:

UVM_INFO @            553397000: (sw_logger_if.sv:524) [dv_log_smoketest_vanilla_sram(sw/device/tests/test_framework/dv_log_smoketest.c:14)] SW-DV log smoketest starting...
UVM_INFO @            560717000: (sw_logger_if.sv:524) [dv_log_smoketest_vanilla_sram(sw/device/tests/test_framework/dv_log_smoketest.c:15)] a = 10, b = 20, c = 12
UVM_INFO @            565357000: (sw_logger_if.sv:524) [dv_log_smoketest_vanilla_sram(sw/device/tests/test_framework/dv_log_smoketest.c:16)] a + b + c = 42
UVM_INFO @            568337000: (sw_logger_if.sv:524) [dv_log_smoketest_vanilla_sram(sw/device/tests/test_framework/dv_log_smoketest.c:17)] Smoke test for the SW-DV log interface, completed successfully!

rswarbrick

This looks really good to me.

Thanks for the updates (and for teaching me about variadic macros in C...)

marnovandermaas

Some comments from my end.

marnovandermaas · 2026-07-15T10:13:00Z

@engdoreis what do you think of this? Are we reinventing the wheel here?

marnovandermaas · 2026-07-15T10:16:46Z

+    va_list args;
+    va_start(args, log);
+    for (uint32_t i = 0; i < log->nargs; i++) {
+        DEV_WRITE(&dv_window->log, va_arg(args, uint32_t));


Why is this 32-bit and not 64-bit?

DV monitor consumes 32-bit beats, a 64 bits value would be truncated with today's implementation

marnovandermaas · 2026-07-15T10:17:16Z

+void dv_log_write(const log_fields_t *log, ...)
+{
+    dv_window_t dv_window = mocha_system_dv_window();
+    DEV_WRITE(&dv_window->log, (uint32_t)(uintptr_t)log);


Pointers are 64-bit right?

The sim SRAM window is only 32-bits and the sw_logger_if only samples 32-bits and the upper bits have an assertion in the tb.sv to ensure it's always the case

engdoreis · 2026-07-15T12:40:44Z

+
+    DV_LOG_INFO("SW-DV log smoketest starting...");
+    DV_LOG_INFO("a = %d, b = %d, c = %d", 10, 20, 12);
+    DV_LOG_INFO("a + b + c = %d", 42);


do you want to also test %x, %c, %s?

Should also test priting a capability since you added support for it.

Good idea on %x/%c/%s - I'll add a line exercising them to the smoketest.

On printing a capability: the log arg path only carries 32-bit values (dv_log_write reads each arg as va_arg(uint32_t)), so we can log a capability's address via %x/%p but not the full 128-bit capability. The CHERI support in this PR is about extracting the log database from a CHERI-built ELF and writing the log port safely (VOLATILE_WRITE), both already exercised end-to-end by the dv_log_smoketest_cheri variant. Did you mean logging an address, or were you thinking of the DB extraction that the _cheri test already covers? Full 128-bit capability logging would need a wider arg path, which I'd suggest as a follow-up.

@engdoreis, I did a test actually and it seems that the %c isn't cleanly supported by the upstream cleanup: it rewrites %c to %0c (the same way %d becomes %0d), and SV $sformatf rejects %0c (*W,SYSFMW: Illegal format ignored), so the log warns even though the char still prints. %x/%s are fine. I can either drop %c from the smoketest or fix cleanup_format to leave %c untouched (one-token change, and %0c is invalid SV anyway). Any preference?

For now let's just test the supported formats.

Shall I open an issue to add this later?

The upstream script assumes a 32-bit struct layout (5 x uint32, 20 B, LONG header). Mocha's rv64 log_fields_t uses 8-byte const char * pointer fields, giving a 32-byte struct and an 8-byte QUAD section-address header. Under CHERI those pointers are 16-byte capabilities, forcing 16-byte section alignment, a 16-byte header and 64-byte entries, with the file/format addresses held in __cap_relocs rather than the section. Add a patch that selects the layout from the ELF class and the .logs.fields alignment, and resolves capability pointer fields from __cap_relocs when present. Wire the script into build_sw_collateral_for_sim.py so each CMake install step produces the .logs.txt and .rodata.txt files that sw_logger_if needs at simulation start. Signed-off-by: martin-velay <mvelay@lowrisc.org>

Each call site places a log_fields_t entry in a new .logs.fields ELF section; extract_sw_logs.py produces the database consumed by sw_logger_if to decode printf-style messages at simulation start, with no UART overhead. Add a log field at offset 0x8 of the dv_window_memory_layout struct and route dv_log_write() through mocha_system_dv_window() for CHERI-safe access to the log write port (0x2002_0008). Add the .logs.fields section to the linker script after .rodata so string constants are resolved before log entries are laid out. Add dv_log.h/c implementing the DV_LOG_INFO/WARNING/ERROR/FATAL macros and the runtime dv_log_write() function. Add dv_log_smoketest to verify the end-to-end path. Signed-off-by: martin-velay <mvelay@lowrisc.org>

Signed-off-by: martin-velay <mvelay@lowrisc.org>

engdoreis

LGTM, but let's wait for Marno's approval before merging.

martin-velay requested review from engdoreis and ziuziakowska June 4, 2026 15:56

martin-velay force-pushed the sw_dv_log branch 2 times, most recently from 7241605 to b88ffc4 Compare June 5, 2026 06:27

KinzaQamar mentioned this pull request Jun 5, 2026

I2C DV -- Device TX-RX test #509

Open

ziuziakowska mentioned this pull request Jun 5, 2026

[hw,dv,sw] Add support for HW_ID for SW #584

Merged

martin-velay marked this pull request as ready for review June 5, 2026 16:05

martin-velay requested review from marnovandermaas and rswarbrick July 10, 2026 09:29

martin-velay force-pushed the sw_dv_log branch from b88ffc4 to 3bc1162 Compare July 15, 2026 08:32

rswarbrick reviewed Jul 15, 2026

View reviewed changes

martin-velay force-pushed the sw_dv_log branch from 3bc1162 to 452cdc2 Compare July 15, 2026 09:40

martin-velay force-pushed the sw_dv_log branch from 452cdc2 to 353cfbb Compare July 15, 2026 09:59

martin-velay requested a review from rswarbrick July 15, 2026 10:00

rswarbrick approved these changes Jul 15, 2026

View reviewed changes

marnovandermaas reviewed Jul 15, 2026

View reviewed changes

engdoreis reviewed Jul 15, 2026

View reviewed changes

martin-velay added 4 commits July 15, 2026 18:02

[dv] Add SW logger support and smoketest sequence

2a4c3e2

Signed-off-by: martin-velay <mvelay@lowrisc.org>

[dv,doc] Update README.md files for logging

d54086c

Signed-off-by: martin-velay <mvelay@lowrisc.org>

martin-velay force-pushed the sw_dv_log branch from 353cfbb to d54086c Compare July 15, 2026 16:29

engdoreis approved these changes Jul 16, 2026

View reviewed changes

Uh oh!

Conversation

martin-velay commented Jun 4, 2026

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

martin-velay commented Jul 15, 2026

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

marnovandermaas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

engdoreis left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants